Diagnosing problems or abnormalities with a computer system is facilitated by industry standards for how motherboard and system vendors present system management information about their products. For instance, problems that occur during startup or runtime, such as memory test failure, system temperature out of range, or system errors may be recorded in a system event log. System event logs are an important part of computer system diagnostics and are specified by industry standards.
According to one industry standard an event log is a fixed-length area within a non-volatile storage media such as non-volatile random access memory (“NVRAM”). Some vendors, to fulfill this requirement in a cost effective manner, store the event log in the same flash memory where the basic input/output system (“BIOS”) is stored. However, the block erasing limitations of flash memory create problems for some operating systems when event data and other information is recorded. In particular, previous systems require a pointer or index address, identifying the next unused or free memory record in the event log, to be updated whenever data regarding a new event is stored. Currently available utility programs depend on this index to read and manipulate event logs. However, due to the limitations of NVRAM, a block erase must be performed before the updated index can be written to the log. Block erasing requires the entire block of flash memory to be saved to random access memory (“RAM”), updated, and then erased from the NVRAM before re-writing the updated information. As a result, it may take as long as six to eight seconds to save, update, erase, and rewrite a 64 kilobyte block of flash memory. For this reason, the size of the event logs may be limited to 16 kilobytes or less to keep the block erasing that accompanies event log recording in previous systems to a minimum.
When events are recorded during runtime, a System Management Interrupt (“SMI”) is generated by the computer system hardware. This interrupt is transparent to the operating system and gives control of the system to a System Management Mode (“SMM”) state until the recording is completed. The operating system will not notice the SMM state and will respond as if the operating system is hung after a period of time. If interrupting the operating system to record system event data in an event log takes longer than allowed by the operating system, the operating system may require a system reboot. Furthermore, computers that are expected to be highly available such as server computers cannot afford to be non-responsive during the SMM.
It is with respect to these considerations and others that the various embodiments of the present invention have been made.